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Обо мне 


Алексей, разработчик СііскНоиѕе. 
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ClickHouse 


не тормозил; 
не тормозит; 


будет не тормозить ещё больше. 
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Оптимизациа производительности 


Профилирование на разных нагрузках. 


Оптимизация всего, что вылезает. 


Про тестирование производительности — смотрите доклад 
Александра Кузьменкова завтра в 10 утра. 


https://www.techdesignforums.com/practice/technique/ 
inning-at-whac-a-mole-redesigning-an-rf-transceiver/ 
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Эпизод 1: МегдеТгее vs Memory 


В ClickHouse есть разные «движки таблиц». 
МегдеТгее таблицы хранят данные на диске. 
Метогу таблицы хранат данные в оперативке. 
Память быстрее, чем диски“. 


Значит Memory таблицы быстрее, чем МегдеТгее? 


* Что значит «быстрее»?. Скорость последовательного чтения и записи. Задержки случайных 
чтений и записи. ІОР5 при заданном параллелизме и распределении нагрузки. 


Конечно память может быть медленнее, чем дисковая подсистема, 
например одноканальная память уз. 10x РСІе 4.0 SSDs. 
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МегдеТгее vs Memory 


Memory таблицы хранят данные в оперативке. 


МегдеТгее таблицы хранят данные на диске, 
точнее в файловой системе. 


Но данные из файловой системы попадают в раде сасће. 
И затем читаются уже из оперативки. 


Значит нет разницы между Memory и МегдеТгее таблицами 
в случае наличия данных в раде сасће2 
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МегдеТгее vs Memory 


Очевидные случаи, когда MergeTree быстрее, чем Memory. 


МегдетТгее таблицы имеют первичный ключ ивторичные индексы, 
и позволяют читать только нужные диапазоны данных. 


Memory таблицы позволяют только full scan. 
Но этот случай не интересен. 


А npn full scan может МегдеТгее быть быстрее, чем Memory? 
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МегдеТгее vs Memory 


Неочевидные случаи, когда MergeTree быстрее, чем Memory. 


МегдеТгее таблицы хранят данные в сортированном порядке 
по первичному ключу. 


Некоторые алгоритмы в СііскНоиве эксплуатируют 
преимущества локальности данных, если она есть (fast path). 


Например, если при GROUP ВУ подряд дважды встретилось 


одно и то же значение, то мы не делаем повторный ПОИСК В хэш-таблице. 


Про хэш-таблицы в ClickHouse смотрите доклад Максима Киты завтра в 12:50. 


А если данные в таблицах находятся в одинаковом порядке, 
может ли МегдеТгее быть быстрее, чем Memory? 
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Как обрабатываются данные в СііскНоцве 


Данные в СііскНоиве хранятся по столбцам 
и обрабатываются тоже по столбцам. 


Array of Structures Structure of Arrays 

struct Point3d struct Points 
float x; std::vector<float> x; 
float y; std::vector<float> y; 
float Z; std::vector<float> 2; 


Т 
510: :уесіог<РоіпіЗа> points; 
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Как обрабатываются данные в СііскНоцве 


Данные в СііскНоиѕе хранятся по столбцам 
и обрабатываются тоже по столбцам. По кусочкам столбцов. 


е Сһипк 
550: : местог<?1оаї> х; 


510: :vector<float> у; 
550: : уесфог<РТоат> 2; 


514: : мтесіог<Сһипк> chunks; 


— Morsel-based processing. 
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Как именно читаются данные из таблицы? 


В случае МегдеТгее: 

— читаем сжатые файлы из файловой системы; 
— вычисляем и сверяем чексуммы; 

— разжимаем сжатые блоки; 


— десериализуем кусочки столбцов; 


2. 
-- обрабатываем их; Это не оптимально 
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Как именно читаются данные из таблицы? 


В случае Метогу: 


— в оперативке уже находятся готовые 
кусочки столбцов, 


обрабатываем их; 


Это более оптимально 
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Что именно происходит при чтении? 


В случае МегдеТгее: 
1. Читаем сжатые файлы из файловой системы: 


— читать можно с помощью синхронного (геаа/ргеаа, ттар) 
или асинхронного (AIO, uring) ввода-вывода; 


— в случае синхронного ввода-вывода, можно 
использовать (обычный геаа или ттар) 
или не использовать раде cache (О ОРЕСТ); 


— если читать из раде сасће без ттар, 
то будет копирование из раде сасће в иѕегѕрасе; 


— читаем сжатые данные — если коэффициент сжатия большой, 
то доля времени в обработке запроса маленькая; 
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Что именно происходит при чтении? 


В случае МегдеТгее: 
2. Разжимаем сжатые блоки: 
— по-умолчанию используется 174%; 


— можно выбрать как более сильный метод сжатия (ZSTD), 
так и более слабый, например вообще без сжатия (МОМЕ); 


— иногда МОМЕ внезапно работает медленнее, с чего бы это? 


— аблоками какого размера были сжаты данные? 
и как это влияет на скорость? 


* Смотрите доклад «Как ускорить разжатие 174» с HighLoad++ Siberia 2018. 
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Что именно происходит при чтении? 


В случае МегдеТгее: 

3. Десериализуем кусочки столбцов: 

— десериализации как таковой нет; 

— это просто перекладывание данных (тетсру); 


— азачем вообще нужно перекладывать данные? 
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Отличие МегдеТтее и Memory 


В случае Метогу: 
— готовые кусочки столбцов в оперативке. 


В случае МегдеТгее: 


— Кусочки столбцов формируются динамически при чтении. 


МегдеТгее делает больше работы, 
но может ли это иногда быть оптимальнее? 
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МегдеТгее vs Memory 


В случае МегдеТгее: 
— кусочки столбцов формируются динамически при чтении, 


и их размер в числе строк может выбираться адаптивно 
ДЛЯ кэш-локальности! 
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Кэш-локальность 


С какой скоростью работает оперативка? 
— какая оперативка, на какой машине? 


С какой скоростью работает кэш? 
— кэш какого уровня, на каком СРО? 
— один или все вместе? 


С какой скоростью чего? 
— throughput, [атепсу?.. 
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Эпизод 2: сжатие данных тормозит? 


В ClickHouse данные по-умолчанию хранятся сжатыми. 
При записи сжимаются, при чтении — разжимаются. 
Профилируем запросы... 


В топе по СРО — функция 174 _десотге55_5ате. 


© Чтобы всё ускорить, надо просто убрать сжатие данных? 
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Пробуем убрать сжатие данных 


Но ничего хорошего из этого не выходит: 


1. Убрали сжатие данных и теперь они не помещаются на диск. 


2. Убрали сжатие данных и теперь чтение с диска тормозит. 


3. Убрали сжатие данных и теперь 
меньше данных помещается в раде сасће. 


Но даже если несжатые данные помещаются целиком 
в оперативку — имеет ли смысл не сжимать их? 
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Что быстрее: разжатие или тетсру2 


Функцию memcpy используют как baseline 
самого слабого сжатиа или разжатиа в бенчмарках. 


Конечно, это самый быстрый эталон для сравнения. 
Пример: 

— memcpy: 12 ГБ в секунду. 

— 174 decompression: 2..4 ГБ разжатых данных в секунду. 


Вывод: memcpy быстрее, чем разжатие 174? 
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Что быстрее: разжатие или тетсру2 


Рассмотрим сценарий: 


— данные хранятся в оперативке; 
— данные обрабатываются по блокам; 

— каждый блок достаточно небольшой и помещается в кэш CPU; 
— обработка каждого блока помещается в кэш CPU; 

— данные обрабатываются в несколько потоков; 


Данные читаются из оперативки, дальше используется только кэш СРЏ. 
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Что быстрее: разжатие или тетсру2 


Пример: Вугеп 3950 (16 ядер) 


— тетсру: 16х12 ГБ = 192 ГБ в секунду. 
— 174 decompression: 16х2..4 ГБ = 32..48 ГБ разжатых данных в секунду. 
— скорость чтения из памяти: 30 ГБ“ в секунду. 


В случае тетсру чтение упирается в скорость памяти. 


Но если используется сжатие, то из памяти читается меньше данных. 
Память работает как диск. Разжатие 124 быстрее, чем memcpy? 


* память двухканальная, но работает не на максимальной частоте. 
По спецификации для этого СРЏ до 48 ГБ в секунду. 
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Что быстрее: разжатие или тетсру2 


Пример: 2 х АМО ЕРҮС 7742 (128 ядер) 
8 channel memory, тах throughput 190 GiB/s 


Для этого сервера работа с данными, 
сжатыми | 24, также будет быстрее. 


Но если ядер меньше — уже не всё однозначно. 


Если данные хорошо сжаты, то разжатие всё-таки упирается в СРЏ, 
а значит, его можно ускорить! 
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Оптимизации в СііскНоиве 


Для Метогу таблиц: 


— Уменьшили размер блока при записи 
для лучшей кэш-локальности обработки данных #20169. 


— Возможность сжатия Метогу таблиц #20168. 
Для МегдеТгее таблиц: 
— Убрали лишнее копирование для режима сжатия МОМЕ #22145. 


— Возможность отключить чексуммы при чтении #19588, 
но использовать эту возможность не надо. 


— Возможность чтения с помощью ттар #8520, чтобы убрать 
лишнее копирование из раде cache а также кэш memory mappings 
#22206. 
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milovidov-desktop :) Bye. 


Выводы 


Чтобы оптимизировать производительность, нужно всего лишь: 
— точно знать, что делает ваш код; 
— профилировать систему на реалистичных сценариях нагрузки; 


— представлять возможности железа; 


— не забывать что в системе много ядер, а у процессора есть кэш; 
не путать latency и throughput :) 
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Спасибо! 
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